1. Field of Invention
Most existing application software in business data processing area treat a date in a format similar to "MM/DD/YY" or "YY/DDD", using 2 digits to carry the last 2 digits of a 4 digit year number, resulting in 2 digit year numbers. For example, the year number 1996 is input, stored, processed, and displayed as "96". However, starting at year 2000, this will cause problems because "00" could be interpreted as either "1900" or "2000", and for example the length of a period from 1996 to 2000 could be negative if96 is subtracted from 00. This problem is known as the "Year 2000 (Y2K) Problem" in the industry, and has been considered a crisis.
This invention solves the problem by changing the data input/output mechanism, the storage and processing of 2 digit numbers, such that the higher digit of a 2 digit number is treated as hexadecimal, and thus 160 (instead of 100) years can be represented with a 2 digit year number. The problem is solved solely from the system side, no change is needed for application software source code in high level languages. Year numbers beyond 1999 are still 2 digit; the displayed and printed out year numbers are decimal-like and self-explanatory. With this invention, the existing application software can continue to work after year 1999.
2. Description of Prior Art
The "Year 2000 Problem" has been noticed and considered catastrophic since 1993, but so far actually no effective and easy solution is proposed for the problem.
IBM proposed several solutions, mainly:
1) Continuing to use 2 digit year numbers with a configurable "sliding century window". For example, use numbers 60 to 99 to represent years 1960 to 1999, and 00 to 59 to represent years 2000 to 2059. While the sliding window mechanism is implemented in the system side, the application software need be modified to setup and change the window accordingly. However, for some, if not all, applications this solution is not practical, because a window of 100 years could be too small, for example it is quite possible a person born in 1920 is still alive in 2020. The existing databases and/or data files make the situation even worse, because before a window can be derided for a particular application a user has to know what is the earliest year number stored in the databases and/or data files.
2) Changing year numbers from 2 digit into 4 or 3 digit. IBM announced their new 4 digit (year number) compliant system software which will provide 4 digit year numbers to the applications, therefore newly developed application software can begin to use 4 digit year numbers. However, existing application software source code need be modified to use 4 digit year numbers before a re-compilation.
Solution solely from the system side is considered not possible. This is because the system per se, either the hardware or the software, can not distinguish which particular 2 digit field is used for a year number (and which is not). In the mean time, a 2 digit field is considered anyway too small for year numbers after 1999 if sliding century window is not used. Although theoretically the space for a 2 digit field can accommodate at least 256 states if it is used to carry a hexadecimal number, the input/output and the processing remain problems (for example, no user will accept the idea to use either "60 h" or "x'60" to represent the year 1996), and more importantly the compatibility between the new software and the existing data files and databases is a big problem.
Therefore, most efforts are focused on the application software side, and changing these 2 digit fields into 3 or 4 digit seemed to be the only practical approach. Gary D. Brown predicted in his book "Advanced ANSI COBOL with Structured Programming" (second edition, 1992, Wiley & Sons, page 371) that this would "keep thousands of maintenance programmers busy in the last year of this century". Unfortunately, the change is by no means trivial and cheap. An article on the recent (Aug. 19, 1996) issue of the Fortune magazine even referred the project to be "the biggest single information project the world has ever faced" (page 54).
There has been hot discussion on the Internet for a while on the field size changes, mainly focused on how to organize and implement such a project. Some companies announced computer tools to scan application software source codes, single out these 2 digit fields and change them "automatically" based on some pattern-matching or rule-based analysis.
However, the enforcement of such changes is not only expensive, but also dangerous. There is no systematic way which can guarantee that all appropriate 2 digit fields can be singled out and changed, no matter by human or by some computer tools. Furthermore, the 2 digit year number fields are not only pervasive in the existing programs, but also in the existing data files and databases. That means the data files and the database schema and contents also need be changed. For on-line applications, the blackout time per se, during the data file and/or database conversion, might be unacceptable. Finally, the change from 2 digit into 4 digit could also cause problems on the user interface.